當要採用一個技術前,第一步肯定是要做充分的資料收集與測試。我剛接手這個需求時,我第一步先把公司前端前手的研究進度重新閱覽一遍,並且嘗試建置 POC 專案,確認技術理解。我整理許多要面對的問題點,但說真的...資源少的可憐,理論與概念相當多,但真的有更實務的實作分析資源尤其少。
在開發程式時,我們工程時都知道要去「共用程式碼」,透過模組共用來達到降低整體的程式大小,減少寫重複的程式碼。
然而在微前端開發時,因為模組被切開了,你無法確保你所引用的套件能夠被共用。當然大可全部採用 AMD 打包模式將模組注入在 global,但會另外衍生作用域和版本管理的潛在議題。注入的時機點也成了另一個問題,因為初始化要是舊加載全部的 package 就有點多餘,所以要等「需要時」才加載。
當你把前端拆成不同的 bundle 這件事,同時也代表你就無法使用你平常習慣的「import module」,跨應用模組間的溝通就形成問題。
那微前端可以有哪些相互溝通的機制呢?如果不採用 iframe 為前提,其實 Web Site 的 global 是相同的,所以你操作的所有的記憶體位置也是共享的。這樣思考下來,似乎簡單不少,但全部的東西往 window 丟,似乎也不是什麼好作法。
所謂全域單例狀態就比如 history, i18n... 等等均是,這些資訊是必須統一並同步的,不會有特定應用單獨改變。最容易出問題的就是 history router,目前大多路由工具都自成狀態管理機,但卻不具備面向微前端應用場景的處理。如何管理、通知、同步這些狀態成為微前端的難題之一。
CSS 樣式本身是全域,本身並沒有 scope 概念,經常會到處污染。當微前端被載入時,如果還注入 style 到 head 就可能有污染的危險,如何管理這些一不小心就血流成河的樣式成為一個複雜的工程。
微前端核心目的就是為了達到分散管理,讓每個應用與應用之間解耦。如何在 CI/CD 做好宣告與用和自動化版本管理成了一項繁雜的工程,要處理的基礎架構從打包到伺服器上跑的部署腳本都習習相關。
其實真要講議題細數可以說是相當多,我只能簡單講講。後面會有連續幾個章節都會針對每個議題和解決方案進行完整的說明和實作,這一章節只能說是像目錄一樣簡單提及。